{\rtf1\ansi\ansicpg1252\uc1\deff0
{\fonttbl{\f0\fmodern\fcharset0\fprq2 RobotoMono-SemiBold;}}
{\colortbl;\red0\green0\blue0;\red255\green255\blue255;\red128\green128\blue128;}
\paperw12240\paperh15840\margl1800\margr1800\margt1440\margb1440\f0\fs22\cf0
\pard\plain \ltrch\loch \f0\fs22\b0\i0
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 No implicit state}
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 \tab A temporal program should have no \loch\af0\hich\af0\dbch\af0\uc1\u8220\'93implicit\u8221\'94 state - }
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 Current state is always well-defined}
\par\plain {\f0\fs22\b0\i0 \tab Pausing a multi-threaded program is not guaranteed to produce consistent results.}
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 \tab If I pause a temporal program at cycle N, I should always end up with the same program state. }
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 ## Can we go over the whole \loch\af0\hich\af0\dbch\af0\uc1\u8220\'93atomic change old state into new state\u8221\'94 in more detail?}
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 ### Atomic: }
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 From the code\loch\af0\hich\af0\dbch\af0\uc1\u8217\'92s point of view, a program\u8217\'92s state can never be \u8220\'93partially modified\u8221\'94. A temporal programming language must enforce that every line of code sees the same consistent view of the universe during evaluation, even if }
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 This has some knock-on effects: A temporal programming language compiler _must_ be able to prove that all possible evaluation graphs contain at most one assignment }
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 ### Change:}
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 Unlike pure functional programming languages, state _does_ change. Unlike most imperative programming languages, \loch\af0\hich\af0\dbch\af0\uc1\u8220\'93change\u8221\'94 can include things like type changes - it\u8217\'92s perfectly valid to say that X\u8217\'92s old type is \u8220\'93apple\u8221\'94 and its new type is \u8220\'93orange\u8221\'94.}
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 Flip a coin and lock/unlock the door example}
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 ### Old/New:}
\par\plain {\f0\fs22\b0\i0 A temporal program\loch\af0\hich\af0\dbch\af0\uc1\u8217\'92s operations must form a directed acyclic graph - the \u8220\'93old\u8221\'94 state is always read-only and \u8220\'93new\u8221\'94 state must always be computed from the old state plus external inputs. Because the \u8220\'93direction\u8221\'94 of computation is always explicit, the lexical ordering of statements in a block has no effect on the computation. You can read the new value of X \u8220\'93lexically before\u8221\'94 you\u8217\'92ve assigned it, as long as you don\u8217\'92t create a feedback cycle. Branch statements don\u8217\'92t \u8220\'93change control flow\u8221\'94, they select or deselect blocks of statements for evaluation. Similarly, \u8220\'93calling\u8221\'94 a function doesn\u8217\'92t immediately execute it, it just marks the statements in that function as belonging to the current moment\u8217\'92s evaluation graph.}
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 ### State}
\par\plain {\f0\fs22\b0\i0 A temporal program\loch\af0\hich\af0\dbch\af0\uc1\u8217\'92s state must persist even if no changes are currently being evaluated. \u8220\'93State\u8221\'94 can refer to both data stored in memory and data implicitly stored in the type system (UnlockedDoor/LockedDoor). }
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 The phrase \loch\af0\hich\af0\dbch\af0\uc1\u8220\'93compute new state from old state\u8221\'94 sounds so generic that it\u8217\'92s more like a design pattern than a paradigm. Why call it a paradigm?}
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 From the software world viewpoint it does seem to It seems much broader than a pattern, and saying that the entire FPGA/ASIC industry follows a \loch\af0\hich\af0\dbch\af0\uc1\u8220\'93design pattern\u8221\'94 sounds incongruous.}
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 Temporal programming is not just about \loch\af0\hich\af0\dbch\af0\uc1\u8220\'93computing new state from old state\u8221\'94, it\u8217\'92s about how that computation is expressed in the language - does the compiler enforce that all state changes are atomic?}
\par\plain \f0\fs22\b0\i0
\par\plain \f0\fs22\b0\i0
\par\plain \f0\fs22\b0\i0
\par\plain \f0\fs22\b0\i0
\par\plain \f0\fs22\b0\i0
\par\pard\plain \tx0\tx360\tx720\tx1080\tx1440\tx1800\tx2160\tx2880\tx3600\tx4320\ltrch\loch {\f0\fs22\b0\i0 A recurrence is a mathematical function that defines a sequence of values \{x0, x1, x2...\} given a starting value x0 and a recurrence relation "x' = f(x)" that defines how to compute each element in the sequence from the previous values.}
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 Temporal programming is a paradigm in which programs are expressed solely as recurrences. In the above definition, "x" represents the entire state of the program and "f(x)" computes the next state of the program as a function of the previous state.}
\par\plain {\f0\fs22\b0\i0  }
\par\plain {\f0\fs22\b0\i0  The ideas behind temporal programming have been around for decades, but "pure" temporal programming languages still don't exist yet. Once they do, they should allow us to do some very interesting things.}
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 Temporal programming is a generalization of the exceedingly common "new_state = f(old_state)" pattern that appears in...}
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 We call a program "temporal" if it relies on the ability to atomically change "old" state into "new" state.}
\par\plain \f0\fs22\b0\i0
\par\plain {\f0\fs22\b0\i0 A temporal program advances from state to state like a ticking clock, with each new state being a pure function of the previous one.}
\par\plain \f0\fs22\b0\i0
\par\plain \f0\fs22\b0\i0
\par\plain \f0\fs22\b0\i0
\par\pard\plain \ltrch\loch \f0\fs22\b0\i0
\par\plain \f0\fs22\b0\i0
\par\plain \f0\fs22\b0\i0
\par\plain \f0\fs22\b0\i0
\par\plain \f0\fs22\b0\i0}